1. Field of Invention
This invention relates generally to the translation of identity information between directory servers in enterprise computer networks.
2. Prior Art
A typical identity management deployment for an organization will incorporate a directory service. In a typical directory service, one or more server computers host instances of directory server software. These directory servers implement the server side of a directory access protocol, such as the X.500 Directory Access Protocol, as defined in ITU-T Rec. X.519 “Information technology—Open Systems Interconnection—The Directory: Protocol specifications”, or the Lightweight Directory Access Protocol (LDAP), as defined in the document “Lightweight Directory Access Protocol (v3)”, by M. Wahl et al of December 1997. The client side of the directory access protocol is implemented in other components of the identity management deployment, such as an identity manager or access manager.
In order to provide an anticipated level of availability or performance from the directory service when deployed on server computer hardware and directory server software with limits in anticipated uptime and performance, the directory service often will have a replicated topology. In a replicated topology, there are multiple directory servers present in the deployment to provide the directory service, and each directory server holds a replica (a copy) of each element of directory information. One advantage of a replicated topology in an identity management deployment is that even if one directory server is down or unreachable, other directory servers in the deployment will be able to provide the directory service to other components of the identity management deployment. Another advantage is that directory service query operations in the directory access protocol can be processed in parallel in a replicated topology: some clients can send queries to one directory server, and other clients can send queries to other directory servers.
Some directory server implementations which support the X.500 Directory Access Protocol also support the X.500 Directory Information Shadowing Protocol (DISP), as defined in the document ITU-T Rec. X.519, “Information technology—Open Systems Interconnection—The Directory: Protocol specifications”, which specifies the procedures for replication between directory servers based on X.500 protocols.
In many large and multinational enterprises, the deployment might incorporate multiple distinct implementations of a directory server, and there may be directory server implementations that are not based on the X.500 protocols. Examples of directory server implementations that are not based on the X.500 protocols include the Microsoft Active Directory, the Sun Java Enterprise System Directory Server, OpenLDAP directory server, and the Novell eDirectory Server. As there is currently no standard replication protocol between directory server implementations from different vendors that are not both implementing the X.500 protocols, synchronization mechanisms are often used in addition to replication protocols in order to maintain the consistency of directory information between directory servers in the deployment. Synchronization products, such as a metadirectory server, are used in enterprise identity management deployments that incorporate directory server implementations from multiple vendors. These synchronization products interconnect these directory servers, and transfer changes made in one directory server to another directory server, so that all directory servers have copies of the data.
A primary component of the information model of a directory server is the directory information tree. The directory information tree comprises a set of one or more directory entries. Each entry has a distinguished name that is unique amongst the entries in the directory information tree. Each entry comprises a set of one or more attributes. Each attribute has an attribute type, and there is at most one attribute in an entry of each attribute type. Each attribute has one or more values. Each entry has an attribute, objectClass, with one or more values that are names of object classes defining the contents of the entry.
A directory schema defines the semantics associated with each object class and attribute type. The schema specifications for an object class include: the attribute types of attributes which must be present in an entry when the entry has that object class, and the attribute types of attributes which may be present in an entry when the entry has that object class. The schema specifications for an attribute type include: the maximum number of values of the type which can be present in an entry, the syntax of the values of the attribute type, and how values of the attribute are compared with each other. The directory schema is represented in the directory as values of the two operational attributes attributeTypes and objectClasses, as described in “Lightweight Directory Access Protocol (LDAP): Directory Information Models”, by K. Zeilenga, of June 2006.
The choice of schema to use in a directory server is determined by the administrator of the directory server. Some directory server implementations have a single, fixed schema; others are extensible and permit the administrator to add attribute type and object class definitions. Several recommended schemas have been published, including the documents ITU-T X.520|ISO/IEC 9594-6, “The Directory: Selected attribute types”, ITU-T X.521|ISO/IEC 9594-7, “The Directory: Selected object classes”, “Definition of the inetOrgPerson LDAP Object Class” by M. Smith of 2000, “Lightweight Directory Access Protocol (LDAP): Directory Information Models” by K. Zeilenga of June 2006, and “Lightweight Directory Access Protocol (LDAP): Schema for User Applications”, by A. Sciberras of June 2006.
All or a subset of the entries held by a directory server in its directory information tree can be exported to a text file. One format for representing directory entries in a text file is the Lightweight Directory Access Protocol Data Interchange Format (LDIF), described in the document “The LDAP Data Interchange Format (LDIF)—Technical Specification”, by G. Good, of June 2000. There are two LDIF formats: the LDIF content format, in which there is one record in the file for each entry to be represented, and the LDIF changes format, in which there is one record in the file for each change to a directory entry to be represented. Another format for representing directory entries in a text file is Directory Services Markup Language (DSML), described in the document “Directory Services Markup Language (DSML)”, by J. Tauber, T. Hay, T. Beauvais, M. Burati, and A. Roberts, of December 1999. Another format for representing directory entries in a text file is Service Provisioning Markup Language, described in the document “Service Provisioning Markup Language (SPML) Version 1.0” by D. Rolls of October 2003. As each entry in the directory information tree has a distinguished name that is unique among all the entries in the directory information tree, each record in a DSML file, in an LDIF file in the LDIF content format, or in a SPML file comprising a SearchResponse has a distinguished name that is unique among the records for entries in that file.
A metadirectory, as described in U.S. Pat. No. 7,191,192 B2 to Yellepeddy et al, is a software product which translates the contents of one data repository to be appropriate for use in another repository, in which the data repositories may be directory servers or other forms of databases. One primary use of a metadirectory is the translation of directory entries from one schema to another, for deployments in which two or more implementations of directory servers are present, and the directory servers have fixed incompatible schemas.
Another data representation framework is the Resource Description Framework (RDF), as described in the document “Resource Description Framework (RDF): Concepts and Abstract Syntax”, by G. Klyne and J. Carroll, of February 2004. In RDF, statements concerning a resource are represented as a collection of triples. The three fields of a triple are the subject resource identifier field, the predicate field, and the object field.
There are two kinds of subject resource identifier field of an RDF triple: the URI kind and the anonymous kind. In the URI kind of resource identifier field, the resource identifier field comprises a Uniform Resource Identifier (URI), as defined in the document “Uniform Resource Identifier (URI): Generic Syntax”, by T. Berners-Lee, R. Fielding, L. Masinter, of January 2005. In the anonymous kind of resource identifier field, the resource identifier field comprises a combination of an input source identifier, and a string value. In the anonymous kind of resource identifier field, the string value is unique within the context of the input source.
The predicate field of an RDF triple is a Uniform Resource Identifier. An example of a predicate is the URI “http://www.w3.org/1999/02/22-rdf-syntax-ns#type”, which specifies as the object the identifier of an OWL class of which the individual incorporating a triple with this predicate is an instance.
There are two kinds of object field of an RDF triple: a data type object field kind, and a reference object field kind. The data type object field comprises a literal value string, and optionally, a parse type string, a data type string, and a language string. The reference object field kind comprises a resource identifier that specifies either the URI of a resource, or an anonymous identifier for a resource.
An ontology comprises a set of class and individual definitions, written in a machine-processable ontology language, such as the “Web Ontology Language” OWL described in the document “OWL Web Ontology Language Overview”, by D. McGuinness and F. van Harmelen, of February 2004. OWL extends the RDF model to add class, property and individual definitions. One example of an OWL ontology is the “FOAF Vocabulary Specification 0.9” by D. Brickley and L. Miller of 24 May 2007.
An OWL class definition specifies a set of properties that individuals of that class may have, as well as the relationships between that class and other classes. An OWL class is defined by a collection of one or more RDF triples in which the subject of the each of triples is the identifier of the class, and one of those triples has the predicate URI “http://www.w3.org/1999/02/22-rdf-syntax-ns#type” with the reference identifier the URI “http://www.w3.org/2002/07/owl#Class”.
OWL defines four kinds of properties: object properties, datatype properties, annotation properties and ontology properties. OWL object properties connect two OWL individuals, and are defined as an instance of “http://www.w3.org/2002/07/owl#ObjectProperty”. OWL datatype properties connect an OWL individual into a datatype value, and are defined as an instance of “http://www.w3.org/2002/07/owl#DatatypeProperty”. OWL annotation properties provide additional descriptions in an OWL individual, class or ontology, and are defined as an instance of “http://www.w3.org/2002/07/owl#AnnotationProperty”. OWL ontology properties provide additional definitions in an OWL ontology, and are defined as an instance of “http://www.w3.org/2002/07/owl#OntologyProperty”.
An OWL individual is an instance of one or more OWL classes. Each individual has a resource identifier that names the individual. An OWL individual is defined by a collection of one or more RDF triples in which the subject of the triples are the identifier of the individual, and one of those triples has the predicate URI “http://www.w3.org/1999/02/22-rdf-syntax-ns#type” with the object of the reference object field kind with the reference identifier incorporating the URI of an OWL class.